home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
inet
/
ddn_news
/
bltn_41.txt
< prev
next >
Wrap
Text File
|
1991-07-10
|
19KB
|
390 lines
**********************************************************************
DDN MGT Bulletin 41 DCA DDN Defense Communications System
7 Oct 88 Published by: DDN Network Info Center
(NIC@SRI-NIC.ARPA) (800) 235-3155
DEFENSE DATA NETWORK
MANAGEMENT BULLETIN
The DDN MANAGEMENT BULLETIN is distributed online by the DDN Network
Information Center under DCA contract as a means of communicating
official policy, procedures and other information of concern to
management personnel at DDN facilities. Back issues may be read
through the TACNEWS server ("@n" command at the TAC) or may be
obtained by FTP (or Kermit) from the SRI-NIC host [26.0.0.73 or
10.0.0.51] using login="anonymous" and password="guest". The pathname
for bulletins is DDN-NEWS:DDN-MGT-BULLETIN-nn.TXT (where "nn" is the
bulletin number).
**********************************************************************
DEFENSE DATA NETWORK PACKET SWITCH SOFTWARE DEPLOYMENT
MANAGERIAL INFORMATION
DCA Msg 281940Z Sep 88
Subject: Defense Data Network Packet Switch Software Deployment
Managerial Information
Reference: DCA Msg 281941Z Sep 88, Defense Data Network Packet Switch
Software Deployment, Technical Information
1. Defense Data Network Packet Switch Software Deployment
By this message the Defense Communications Systems Data Systems (DCSDS)
a. Establishes the plan for deploying the Defense Data Network's Packet
Switching Node Release 7.0 New End-to-End (DDN PSN 7.0 NEE) system
to the MILNET (see the deployment schedule in section 2.),
b. Solicits the cooperation and participation of the MILNET subscriber
community during the deployment testing which begins 29 October 1988
(see subscriber testing responsibilities in section 3.),
c. Requests MILNET subscribers to identify their host's X.25 facilities
negotiation capabilities by 1 January 1989 (section 4.), and
d. Provides a brief status of recent activities leading to this stage
of deployment (section 4.).
By the referenced message DCSDS provides a PSN 7.0 technical status based
upon the recent off-line testing with MILNET hosts.
The Defense Data Network (DDN) will soon contain a new version of Packet
Switching Node (PSN) software designated PSN 7.0 NEE, which more strictly
complies with the CCITT Recommendation X.25. The strict adherence to
standards requires a deliberate deployment approach coordinated with
subscribers to ensure continuity of MILNET operations. Subscribers who do
not participate in the activities preparatory to the final PSN 7.0 NEE
deployment risk loss of MILNET service due to incompatibility. Consequently,
request all addressees to acknowledge receipt of this message to DCA
WASHINGTON DC //B610//. (Note: Based upon the ARPANET Beta testing, AHIP
user impact is not acticipated; however, prudent MILNET testing indicates
that AHIP subscribers should also participate.)
2. PSN 7.0 NEE Deployment Approach and Schedule
The PSN 7.0 NEE deployment is the second phase of the PSN 7.0 deployment on
MILNET. (Phase 1 was the MILNET deployment of PSN 7.0 Old End-to-End (OEE),
a PSN 6.0-compatible system, achieved by 30 August 1988.) The Phase 2
deployment will consist of five interim short duration cutover tests and a
final permanent cutover. The interim cutovers will provide ample opportunity
for both subscribers and network analysts to participate in a MILNET
operational test of PSN 7.0 NEE prior to its permanent operational use. The
first three interim cutovers will occur on weekends. The next two cutovers
will occur on a weekday to maximize the PSN 7.0 NEE system's exposure in the
MILNET. The final cutover will take place at the begining of the week. The
cutover schedule follows:
Day Time
Cutover Zulu/Eastern Zulu Eastern Duration
C1 29/29 Oct 88 1600Z 1200 EDT 12 hours
C2 12/12 Nov 88 1100Z 0600 EST 12 hours
C3 19/19 Nov 88 1100Z 0600 EST 24 hours
C4 30/30 Nov 88 0501Z 0001 EST 24 hours
C5 14/14 Dec 88 0501Z 0001 EST 24 hours
C6 09/09 Jan 89 0501Z 0001 EST Permanent
The dates are subject to modification as testing proceeds depending on test
results. The dates also are negotiable for military exigencies. Additional
tests may be scheduled on an individual host or MILNET-wide basis. DCSDS
will notify the subscriber community of any schedule modifications.
3. Procedures and Operational Support for Phase 2 Deployment
The first hour of each period in section 2. above will be dedicated to the
cutover of PSN 7.0 from OEE to NEE, a MILNET-wide cutover. The Cambridge
Monitoring Center (CMC) will cutover groups of PSNs at a time to NEE. DCSDS
directs subscribers not to attempt communications during this period for two
reasons: the cutover segments the network and taxes network resources. Thus,
communications will be slow or nonexistent during the hour.
The second hour of the test period will mark the beginning of the operational
test. DCSDS asks subscribers to participate in the test by exercising their
normal applications and reporting anomalies to the Monitoring Center Trouble
Desk in their respective areas (the PMMC, CMMC or EMMC) using established
reporting procedures. Should the Trouble Desk's telephone be busy, please
call again. If you can still not reach the Trouble Desk, please report your
problem via electronic mail to MILUPGRADE@BBN.COM, using the format
outlined in the next paragraph. Additional staff will support the Trouble
Desks during the testing periods. Also, network analysts located at the CMC
will provide expert assistance.
In order to efficiently utilize the Trouble Desks, DCSDS asks those people
reporting problems to give the following information to the operator:
a. Reporter's Name
b. Reporter's Telephone Number (both Autovon and Commercial)
c. Reporter's Address
d. URDB Subscriber/System Name
e. IP Address
f. Equipment Manufacturer and Model Designator
(Specify Host, Front End, PADs, etc. as appropriate)
g. Software Manufacturer and Product Designator
(Specify Operating System, Network Protocol (X.25B, X.25S, HDH,
1822), Upper Level Protocols, Application Packages, etc. as
appropriate and available)
h. Statement of Problem
Attempted Activity or Function
Expected Result
Actual Result
Impact on User
i. Availability for follow-up test during test period, hours of
availability in Zulu time
j. Follow-up test POC if different from reporter
DCSDS asks subscribers to assist MC personnel as necessary in duplicating
problems to enable an accurate analyses. See Section 4.1 for additional
testing procedures.
The last hour of the test period will be dedicated to cutting back to PSN 7.0
OEE. The same caveats apply to this hour as to the first hour: do not
attempt communications, service will be slow or nonexistent.
The determination to perform the final cutover will be contingent upon the
alleviation of communications disruptions encountered during the tests.
4. PSN 7.0 Status
4.1 Testing Incidents
The problems already encountered during the off-line testing with MILNET
hosts fall under the categories of administration and X.25 conformance.
Incidents encountered during cutover testing may fill a third category of
non-X.25 errors.
4.1.1 Administrative Problems and Information Request
The off-line testing with MILNET hosts encountered a problem related to flow
control negotiation causing hosts to clear calls. The superseded
configuration of flow control negotiation parameters for certain PSN host
ports caused the problem and the particular X.25 implementation of PSN 6.0
and PSN 7.0 OEE masked the problem. A temporary patch will correct the
problem in PSN 7.0 NEE. The MC will remove the patch during the initial
operational phase of PSN 7.0 NEE upon identification and execution of the
configuration modifications.
In order to correct the configurations, DCSDS asks all subscribers to forward
by 1 January 1989 responses to the following questions via front channel
message to DCA WASH DC //B612//:
Can your host currently negotiate
a. window size,
b. packet size,
c. precedence, and
d. throughput class?
What are the minimum and maximum logical channel numbers your host
supports?
4.1.2 X.25 Conformance Problems
The off-line testing also uncovered a problem related to self-addressed calls
which caused hosts to clear calls. In one test case the problem surfaced
during a file transfer test; the implication being that the user need not
explicitly request self-addressing to experience the problem.
DCSDS thus asks all subscribers to exercise as much of their normal
applications or general routines as possible to identify the chance of
service denial after operational cutover to PSN 7.0 NEE.
4.1.3 Non-X.25 Incidents
The off-line testing encountered a problem related to packet sequencing. The
host layer above X.25 (IP) improperly fragmented a message. The problem
workaround (modifying the packet size) indicates that different host
configurations of X.25 interface characteristics can result in terminated
service.
Thus, DCSDS not only asks subscribers to exercise their normal applications,
but also to exercise those applications under their variously configurable
environments.
An outstanding problem from the ARPANET Beta tests relates to the HDH
interface. On a random basis the interface between the BBN packet switch and
an ACC Gateway resets itself. DCSDS has now staffed the problem analysis
effort.
5.0 Points of Contact
The point of contact for any administrative issues regarding this message
(such as test schedules or configuration requirements) is Mr. George
Bradshaw, DCA Code B612, AV 364-5306, Commercial (703)285-5306, Bradshaw
@ DDN1.ARPA. The points of contact for any test procedure questions
are Mr. Mark Whitney (BBN, Commercial (617)873-2874, MWhitney @
BBN.COM) and Mr. Edward Smith (BBN, Commercial (703)848-4838, ESmith
@ BBN.COM). Address questions related to communications protocols
(X.25, IP, etc.) to Mr. Andrew Malis (BBN, AMalis@BBN.COM) with a
courtesy copy to Bradshaw@DDN1.ARPA. Address any issues of general
community interest to MILUPGRADE@BBN.COM.
TECHNICAL INFORMATION
DCA Msg 281941Z Sep 88
Subject: Defense Data Network Packet Switch Software Deployment
Technical Information
Reference: DCA Msg 281940Z Sep 88, Defense Data Network Packet Switch
Software Deployment, Mangerial Information
1. Defense Data Network Packet Switch Software Deployment
This message discusses, in technical terms, the current status of Defense
Data Network Packet Switching Node Release 7.0 New End-to-End (DDN PSN 7.0
NEE) in parallel with section 4 of reference, which provides a managerial
status overview. This message also provides technical details concerning the
recent PSN 7.0 NEE off-line testing with MILNET hosts.
2. PSN 7.0 Definition
PSN 7.0 is the newest release of software for the DDN's packet switching
nodes. PSN 7.0 embodies 1) a PSN 6.0-compatible system designated Old
End-to-End (OEE) to facilitate release deployment and 2) the full capability
system designated New End-to-End (NEE).
NEE consumes up to 50% fewer network resources with X.25 transmissions and
consequently has the potential to improve throughput by a similar percentage
depending upon topological and utilization considerations. These
improvements come primarily through a redesign of subnetwork transport
services and new functionality for network services. The transport service
improvements provide: 1) efficient X.25 acknowledgment handling throughout
the network, and 2) flow control for congestion within a single packet
switching node. The network service functions support 1) four levels of
precedence and 2) pre-emption to guarantee throughput of critical traffic
during periods of high network utilization.
3. PSN 7.0 NEE Testing
PSN 7.0 will have undergone five distinct periods of testing prior to
operational use on the MILNET:
early 1987 Development Testing
late 1987 Beta Testing on ARPANET
mid 1988 Off-line Testing with MILNET hosts
mid 1988 Phase 1 (OEE) Deployment on MILNET
early 1988 Phase 2 (NEE) Deployment on MILNET
Following its beta testing, PSN 7.0 received extensive operational exposure
on the ARPANET and has become a stable system. The recent off-line testing
with MILNET hosts has exposed X.25 problems involving self-addressed calls
and flow control negotiation; both issues are discussed later (PSN 7.0 NEE
tested against systems listed below). DCSDS has completed the deployment of
PSN 7.0 Old End-to-End (OEE) Phase 1. The PSN 7.0 NEE Phase 2 deployment
will consist of controlled interim and final cutovers to the full capability
PSN 7.0 system.
PSN 7.0 NEE Tested with Following Systems
AFLC APDS CCSO/XPNB DLA DSACS
ESD/SCO IDSS IMMIS JACS/J/J NARDAC
NAVTIS NCPDS PASS-SDS PERDIMMS SAF/ACES
3.1 Host Testing Technical Description
Two major problem issues currently exist: 1) the superseded configuration of
flow control negotiation parameters for certain PSN host ports, and 2) the
inability of one communications protocol implementation to handle
self-addressed calls.
3.1.1 Flow Control Negotiation
CCITT Recommendation X.25 specifies flow control methods which allow the DCE
to be either an active (initiator) or passive negotiating element, depending
upon the network implementation. In practice, the PSN configuration
parameters "Window and Packet Size Negotiation Subscription" support this
network dependence. PSN 6.0 and PSN 7.0 OEE ignore the setting of these
parameters and do not actively participate in negotiations. PSN 7.0 NEE
participates in negotiation when the parameters are set to "yes", which is
also the default setting for MILNET. Therefore all MILNET hosts, whether or
not they can participate in flow control negotiation will, under PSN 7.0 NEE,
receive negotiation offerings for window and packet size from the PSN. If
the parameters were set to "no", PSN 7.0 NEE would not send negotiation
offerings to the host. The problem is that hosts which cannot negotiate will
clear a connection if the PSN attempts negotiation.
The resolution to this problem is to configure the PSN host ports properly.
DCSDS has established a deployment approach to 1) provide, in the short term,
a patch to NEE, temporarily reverting the release to PSN 6.0 compatibility,
and 2) define and execute configuration corrections in the long term.
3.1.2 Self-Addressed Calls
CCITT Recommendation X.25 states, in essence for the purposes of this
discussion, that an outgoing and incoming call will exist on different
virtual channels with that difference identified by a unique number called
the logical channel number (LCN). PSN 6.0 and PSN 7.0 OEE did not conform to
the X.25 standard and assigned the same number to an outgoing and incoming
call which was self-addressed. PSN 7.0 NEE conforms to the standard. The
result is that at least one higher level protocol implementation which
apparently was sensitive to this difference has not functioned properly
during the off-line tests under PSN 7.0 NEE. In this case, an FTP
implementation could not transfer files. The configuration for this test was
an IBM 4300 with a Series 1 front end. UCLA ARPANET Control Protocol V1.6
resided in the 4300, EDX V5 resided in the Series 1.
Several alternatives exist for resolving this problem.
a. Replace or correct the protocol implementations which do not abide by the
X.25 standard.
b. Modify the PSN 7.0 NEE software to act like PSN 6.0, bringing it out of
X.25 conformance.
c. Modify the topological aspect of the file transfer by "teleneting" one's
self to the file's destination and "pulling" the file to the destination
rather than "pushing" the file to the destination.
The following caveats apply to the alternatives. Alternative a. places the
onus on host administrators, alternative b. is not in accord with government
policy to follow standards, and alternative c. may cause logistics problems
with userid and password assignment.
The PSN 7.0 NEE cutover testing results will determine the expedient
alternative based upon the types and extent of subscriber impact throughout
the network.
3.1.3 Flow Control Implementations
The PSN 7.0 NEE off-line testing with MILNET hosts uncovered an anomaly in
one implementation of the DOD Internet Protocol. The IP incorrectly
fragmented a TCP message causing the TCP connection to clear. The
fragmentation resulted in two "final" (X.25 Category B) packets for the same
sequence of packets. In the original test the packet size was 256 octets.
The host transmitted a sequence of packets, the first group of which were
correctly category A packets each 256 octets in length. The second to last
packet of the sequence was a category B packet by virtue of its 128 octet
length (not a "full" packet). The last packet of the sequence was also a
category B packet by virtue of its size (seven octets). One experiment
configured a packet size of 128 bytes and yielded a successful workaround
which resulted in a single category B packet of seven octets. The system was
a Sperry 5000 with Adax X25/IP/TCP.
4.0 Points of Contact
The point of contact for any administrative questions is Mr. George Bradshaw,
DCA Code B612, AV 364-5306, Commercial (703)285-5306. The point of contact
for any test procedure questions is Mr. Mark Whitney (BBN, Commercial
(617)873-2874, MWhitney@BBN.COM). Address questions related to
X.25 technical issues to Mr. Andrew Malis (BBN, AMalis@BBN.COM)
with a courtesy copy to Bradshaw@DDN1.ARPA. Address any issues of
general community interest to MILUPGRADE@BBN.COM.